<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>

<head>
<title>Table 7: DML Attributes for Optimizations Configuration</title>
</head>

<body bgcolor="white">

<p align="left">
<b>Table 7: DML Attributes for Optimizations Configuration</code></b> Each
attribute in this table, if used, must appear as an immediate subattribute of
the <code>bgpoptions</code> attribute, which is itself an immediate
subattribute of the top-level <code>Net</code> attribute.
</p>

<table align="center" border="1">

<tr>
<td align="left" valign="center">
<code>radix_trees</code>
</td>
<td align="left" valign="center">
Whether radix trees should be used for implementing the RIB.  If they are not
used, there are typically improvements in memory usage and running time, but
some functionality of BGP becomes unavailable.  The loss of functionality, in
general, applies to anything which requires knowing when two prefixes are
overlapping.  This primarily affects route aggregation.  Since no automatic
aggregation currently takes place in this BGP implementation, this optimization
can currently be used without worry.  The default is false (meaning that radix
trees are not used, and thus the optimization is on).
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>flat_aspaths</code>
</td>
<td align="left" valign="center">
Whether to use an optimization in which AS paths are always a single sequence
of AS numbers.  Using this optimization should reduce memory usage, but it
prohibits route aggregation.  The default is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>linked_aspaths</code>
</td>
<td align="left" valign="center">
Whether to use an optimization in which AS paths are never copied, only stored
as several overlapping linked lists.  Using this optimization prohibits the
simulation from executing distributedly--it must be run on a single machine.
It also prevents attribute modification other than the standard prepending of
AS number when advertising to an eBGP peer.  That is, no AS padding can be done
during the attribute modification part of route filtering.  The default is
false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>basic_attribs</code>
</td>
<td align="left" valign="center">
Whether to use an optimization in which only the three most basic path
attributes are allowed: AS path, LocalPref, and NextHop.  Using this
optimization should improve memory usage, though not necessarily by a large
amount.  Obviously, a lot of BGP functionality will be unavailable when this
option is in use.  This includes, but is not necessarily limited to, the use of
any path attributes besides AS path, LocalPref, and NextHop; route reflection;
and aggregation.  The default is false.
</td>
</tr>

<tr>
<td align="left" valign="center">
<code>simple_policy</code>
</td>
<td align="left" valign="center">
Whether to use an optimization in which the filtering policy always permits all
routes, and assigns degrees of preference which prefer shorter AS paths.  If
this option is used, no filtering policies can be configured in DML--they will
automatically be enforced as described.  The default is false.
</td>
</tr>

</table>


<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>


</body>
</html>
